The HTML, or other, code that makes up each web page on the World Wide Web is commonly dynamically generated by an event-driven program that is running on server hardware. This type of program is known as a web application. In the following, the terms “web server” will be used to refer to the logical entity that provides a web page in response to an http request and “web application” to the set of components that provide this function using general-purpose computing platforms within general-purpose operating environments such as are provided by the Microsoft Windows, Linux or HP-UX operating systems and their related programming libraries and tools.
Web applications are generally event-driven interactive systems which react to HTTP requests from the client, the http request being directed to a web address (a URL). The web application will generate and return a web page to the browser. The difference between this type of arrangement and a simple “static” site is that each action the user takes can have some semantics associated with it. In other words, the resulting web page can differ according to the user, the current time or other factors prevailing in the system.
When the web application receives an event, it is arranged to evaluate the received event and decide how to respond to the client. This evaluation process may involve interaction with business logic of some kind. The interaction with the business logic can take place independently of the screen design or user interface and often involves transactions with back-end systems, such as remote databases.
Web servers typically provide for user sessions which enable session data relating to a series of http requests from a single user to be retained on the server. A modern production web server would normally be arranged to conduct a relatively large number of user sessions in parallel.
Since multiple http requests can be received at the same time by a web server, the processing of requests by a web server is inherently multi-threaded and, in most modern web servers, each request is normally processed by a separate thread or process, depending on the design.
A state machine may be used for controlling a web application. Where a state machine is used to control the web application, each user session will normally have a single state machine instance that will only be affected by http requests pertaining to that session. However some protection of the state machine data for each session must be put in place to avoid concurrency problems due to access by multiple threads processing separate events from the same session, corresponding, for instance, to multiple mouse clicks from a single user. The simplest approach to this is would be to place a lock on the state contexts at the time the state machine starts processing an event. Using this approach, further event processing would then be disabled until processing of the event is complete.
However, it is possible in such systems that a state transition and the generation of a new web page to display may take a significant amount of time and that during that time further events may be deliberately generated by the user. For instance, before a new page can be generated, the user may change their mind as to what they want to do, or may simply lose patience. If the processing of events were to be isolated by holding a coarse-grained lock on event reception until the event is fully processed, there would be no way for a user to change their mind when they click to perform an action that takes a long time to complete: the lock would not allow a new event to be processed until the previous action has run to completion.